Feat/pim/m20 kronknav - #3776

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

Point-LIO accepts malformed FLOAT32 x, y, or z field offsets that begin within point_step but do not leave room for the full four-byte value. A focused AddressSanitizer reproduction confirmed that the accepted message causes an out-of-bounds native read. Rejecting coordinate fields whose typed width exceeds point_step prevents corrupted or untrusted lidar traffic from reaching this unsafe read.

What T-Rex did

• Ran the focused parser reproduction script to reproduce the P1 finding and reviewed the related review comment.
• Opened and inspected the focused parser reproduction source and its accompanying run logs to confirm the repro setup and expectations.
• Validated the general contract by confirming that x_offset=0 is accepted and all reads complete with exit 0, and that x_offset=31 triggers an AddressSanitizer-reported over-read.
• Checked the toolchain readiness using the ASan harness build log, valid point execution, stack trace, and native M20 environment result.

_{Ran code and verified through T-Rex}

1. General comment

   Coordinate field widths are not validated before native reads

   • Bug
     • validate_m20_cloud accepts a FLOAT32 x, y, or z field when its offset is merely below point_step. A one-point cloud with point_step=32, exactly 32 bytes of data, and x.offset=31 passes validation. The subsequent read_unaligned<float> copies four bytes from offset 31, which AddressSanitizer confirmed reads beyond the point/data allocation.
   • Cause
     • The bounds check at lines 157-160 covers timestamp, ring, and intensity only; x/y/z are omitted despite being read as four-byte floats at lines 544-546.
   • Fix
     • Extend the point-step validation to require offsets.x + sizeof(float), offsets.y + sizeof(float), and offsets.z + sizeof(float) to be no greater than cloud.point_step (ideally through one common typed-field bounds helper).

   _{Ran code and verified through T-Rex}